Computer processors are getting faster, yet software application performance is not keeping pace. For large commercial applications, average processor cycles-per-instruction (CPI) values may be as high as 2.5 or 3. With a four-way instruction issue processor, a CPI of three means that only one issue slot in every twelve is being put to good use. It is important to understand why software throughput is not keeping up with hardware improvements.
It is common to blame such problems on memory latencies, in fact, many software applications spend many cycles waiting for data transfers to complete. However, other problems, such as branch mispredicts also waste processor cycles. Independent of the general causes, system architects, and hardware and software engineers need to know which instructions are stalling and why in order to improve the performance of modem computer systems incorporating complex processors.
Typically, this is done by generating a "profile" of the behavior of a system while it is operating. A profile is a record of performance data. Frequently, the profile is presented graphically so that performance bottlenecks can readily be identified.
Profiling can be done by instrumentation and simulation. With instrumentation, additional code is added to a program to monitor specific events during execution of a program. Simulation attempts to emulate the behavior of the entire program in an artificial environment rather than executing the program in the real system.
Each of these two methods has its drawbacks. Instrumentation perturbs the program's true behavior due to the added instructions and extra data references. Simulation avoids perturbation at the expense of a substantial performance overhead when compared to executing the program on a real system. Furthermore, with either instrumentation or simulation, it is usually difficult to profile an entire large scale software system, i.e., application, operating system, and device driver code.
Hardware implemented event sampling can also be used to provide profile information of processors. Hardware sampling has a number of advantages over simulation and instrumentation: it does not require modifying software programs to measure their performance. Sampling works on complete systems, with a relatively low overhead. Indeed, recently it has been shown that low-overhead sampling-based profiling can be used to acquire detailed instruction-level information about pipeline stalls and their causes. However, many hardware sampling techniques lack flexibility because they are designed to measure specific events.
Most extant microprocessors, such as the DIGITAL Alpha AXP 21164, the Intel Pentium Pro, and the MIPS R10000 provide event counters that can count a variety of events, such as data cache (D-cache) misses, instruction cache (I-cache) misses, and branch mispredicts. The event counters generate an interrupt when the counters overflow so that the performance data in the counters can be sampled by higher levels of software.
Event counters are useful for capturing aggregate information, such as the number of branch mispredicts that the system incurred while executing a particular program, or part thereof. However, known event counters are less useful for attributing state information to individual instructions, such as which branch instructions are frequently mispredicted. This may be due to the fact that the program counters (PC) of instructions that caused the events may no longer be available when the event counter overflows and interrupts.
It is a particular problem to deduce the dynamic operation of a processor that can issue instructions out-of-order. Indeed, the behavior of software programs executing in an out-of-order processor can be quite subtle and difficult to understand. Consider the flow of instructions in the out-of-order Alpha 21264 processor as a concrete example.